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M y last column descri bed the d ifferences between 
client Smalltalk systems and server Smalltalk, 
and how server Smalltalk fits into the three-tier 
architecture that is emerging to meet the performance 
and business requirements of enterprise-wide applica¬ 
tions The key to balancing the processing load between 
clients and server, and sharing business objects in such 
architectures, is the ability to partition applications. 

Application partitioning is the activity in which code 
written for the client can be moved to the server (or vice 
versa). When both the client and server can execute the 
same Smalltalk code, this movement of objects and code 
is much simpler and allows the application to be dynam¬ 
ically tuned in the face of changing hardware and soft¬ 
ware. Applications can be developed initially only on the 
client, and then portions can be moved to the server to 
shareobjects, enforce security policy, and gain fault toler¬ 
ance of critical data as needed. 

When the clients and server speak a different language, 
th i s parti ti on i ng shou I d occu r earl i er i n the desi gn, because 
partitioning decisions are more difficult and costly to 
change later. Unfortunately, performance tuning often 
occurs late in the software process so, in many cases, the 
decision to repartition an application must balance the 
cost of reimplementing large sections of code against the 
expected performance gain. Making such changes is dis¬ 
couraged because the cost of repartitioning is higher. Also, 
developers must be proficient in two different languages, 
onefor client development, and one for the server. 

When Smalltalk is the language on both the client and 
server, what mechanisms are available to partition the 
application and to distribute objects and behavior be¬ 
tween the client and server? In GemStone Smalltalk, there 
are several mechanisms available so that client ap¬ 
plications can reference and manipulate objects located 
on the server. One mechanism is forwarders. A forwarder 
is a client object that covers for a server object. A for¬ 
warder does not contain any state of the server object, but 
maintains enough information to communicate with the 
server object when needed. When a message is sent to a 
forwarder, the execution of its behavior actually takes 
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place on the server. The forwarder knows the identity of 
the server object and how to communicate with it. 

Forwarders are implemented in such a way that no 
sped al code is requ i red to check for the presence of a for¬ 
warder before sending it a message. Forwarders utilize 
Smalltalk's message-sending mechanism to automatical¬ 
ly forward messages by special handling of the 
doesNotUnderstand: error. The Forwarder class does not 
inherit from class Object, so forwarders understand very 
few messages on the client side. Most messages to a for¬ 
warder are silently trapped by the execution thread on the 
client, forwarded to the server for execution, and the 
result returned to the client for continuation of its execu¬ 
tion thread. If the message to a forwarder contains argu¬ 
ments, those arguments are transformed automatically 
into server objects if needed. This is implemented in such 
a way so that application code does not have to be written 
any differently, whether the receiver of a message is a for¬ 
warder or some other cl ient object. 

There are several ways a programmer can get a for¬ 
warder to a server object. One way isto send the message 
beForwarderto a replicate (discussed later). For example, a 
newly created client object could be copied to the server 
by sending it the message putlnGS (thus, making it a rep¬ 
licate), then send the message beForwarder. At that point, 
the state of the object is only stored i n the server Smal Ital k, 
and any messages sent to the cl ient object cause execution 
in the server. In some cases, a developer may design the 
application so that all instances of a particular client class 
are intended to be forwarders Whenever an instance of 
such a class is fetched from the server, it should be instan¬ 
tiated asaforwarder.Thisisspecified byimplementingthe 
method instancesAreForwarders in the client class to return 
true. Two other ways to specify that certain objects are to 
be manifested as forwarders in the client Smalltalk is by a 
replication specification (described later) or by a connec¬ 
tor. A connector is a mechanism connecting certain client 
objects with certain server objects at the time the client 
logs i nto the server. There are many different kinds of con¬ 
nectors: some that connect cl asses and some that connect 
class variables; there are those that connect class instance 
variables; those that connect objects by name; and those 
that connect objects by identity. Each type of connectors 
allows a developer to specify that the client object isto be 
manifested as a forwarder. 
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Another mechanism to manipulate server objects on 
the client is with replicates. A replicate is a copy of a server 
object that resides on the client. Someorall of the state of 
the server object is copied in the replicate, and when a 
message is sent to a replicate, the execution of its behavior 
takes place on the client. Using replicates requires that a 
mapping be defined between classes on the client and 
classes on the server. At its simplest, this mapping can 
specify that a server class maps to a client class with the 
same name. This is the default mapping. You can also spec¬ 
ify more complex mappings as objects are translated 
between client and server. Thisisdone by reimplementing 
the instVarMap method in the class of the replicate. This 
method should return nested arrays, where each sub-array 
contains an instance variable name and a specification of 
how it should be mapped. This allows a developer to han¬ 
dle reorderi ng, renami ng, or omission 
of instance variables when an object 
moves from one domai n to the other. 

A key consideration when using 
replicates is the amount of synchro¬ 
nization that occurs between the cli¬ 
ent replicate and its corresponding 
server object. There are messages 
available to the application developer 
to explicitly manage keeping the two 
objects in sync. However, it is much 
easier to let the interface layer that manages replicates be 
responsi ble for keepi ng the state of cli ent and server objects 
in sync. In thisway, a replicate always accurately reflects the 
state of the server object (based on thecurrent transaction’s 
point of view), wherever the object is used in the appli¬ 
cation.This level of synchronization, called full transparen¬ 
cy, is configurable by class. To enable full synchronization 
for a class, send it the message makeGSTransparent. 

When replicates are used in full transparency mode, 
then modifications to replicates are managed automati¬ 
cally. When the application modifies a replicate, it is auto¬ 
matically marked dirty and changes are flushed to the 
server at the appropriate time. For example, modifica¬ 
tions to replicates are flushed to the server before any 
server behavior is executed or when the transaction is 
committed. When other users modify and commit 
changes to server objects, those changes are not seen in 
the replicate until the current transaction iscommitted or 
aborted. At this time, the replicate is eligible to have its 
state updated from the server, a behavior called faulting. 
Ordinarily, the replicate will not be faulted until it is next 
accessed. However, this default behavior can be overrid¬ 
den by implementing a method called faultPolicy for the 
classofthereplicate.Thismethod should return immedi¬ 
ate if the replicate should be faulted immediately when 
the next transaction begins. It is also possible to cause 
additional application codeto be executed beforeor after 
the replicate is faulted by implementing a preFauIt and 
postFauIt method. 

An important consideration when programming with 
replicates is how to control the replication of composite 


objects (objects with nested subobjects). Some client ap¬ 
plications may only need a portion of the state of the serv¬ 
er object, so why send more to the client than is needed? 
When a replicate is being instantiated from a server 
object, an application wants to control which instance 
variables are retrieved and in what form theobjects refer¬ 
enced by those instance variables are created (as for¬ 
warders or replicates). In addition, if the instance variable 
is assigned a replicate, the application may also want to 
specify how many levels deep to replicate. To exercise this 
control, a developer implements the replicationSpec 
method for the class of the repl icate. This method returns 
nested arrays where each subarray contains the name of 
an instance variable and a specification of how it is to be 
instantiated. The developer has the option to specify 
whether the instance variable is to be instantiated as a 
replicate, a forwarder, or a stub (dis¬ 
cussed later). If the instance variable 
is to be created as a replicate, the 
developer can specify a minimum or 
maximum number of levels to rep¬ 
licate as well. The following example 
shows the implementation of the 
replicationSpec method for class 
Employee, where the name instance 
variable is replicated, the address 
instance variable is replicated to at 
least level 2, and thedepartment instance variable iscreat- 
ed as a forwarder. 

classmethod: Employee 

replicationSpec 

"Return nested arrays specifying how Employees are to be 
replicated." 

•'super replicationSpec, 

#( (name replicate) 

(address min 2) 

(department forwarder) ) 

I n cases where not alI of a composite object is copied into 
the client, some placeholder object must take the place of 
each object that remained on the server. Thisobject, called 
a "stub,” maintains information concerning its corre¬ 
sponding object on the server. When a stub is sent a mes¬ 
sage, it has the abi I ity to create a repl icate, replace the stub 
with the new replicate, and then resend the message to the 
replicate. This happens transparently to the end user, so 
application code does not have to test for the presence of 
a stub object. It is also possible to turn a replicate into a 
stub object. This is desirable if you want to free the space 
taken up by the replicate and its subobjects. You can do 
this by sending the message stubYourself to a replicate. 

The mechanismsjust described can be utilized in sev¬ 
eral ways to partition and fine-tune an application for 
maximum performance in a client/server environment. 
Developers can exercise greater control over where exe¬ 
cution of object behavior takes place and how much data 
is transferred to the client. K 


Modifications to 
replica tes are ft ushed to 
the server before any server 
beh a vi or i s execu ted. 
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